Context management
The Session Manager keeps track of information that must span the client/server divide, that is. information that must be available to business logic regardless of whether it is running client or server side. Business logic should not have to be concerned with where it is being run and should function exactly the same in any environment.
To facilitate this, the Repository database has a context database table, shown in Figure 6–4, called gsm_server_context. This table is a generic table used to store context information of any kind between stateless AppServer connections.
As you can see from the table definition, all context records are identified by a session_obj, which joins to a session record in a separate gst_session table. This is based on the session:server-connection-id, which provides a unique code for the current client connection. The ID is maintained from the time of connection to the AppServer until a disconnect statement. The value is also available to the client via the client-connection-id attribute of the AppServer object handle if an AppServer is in use.
For code portability when not using AppServer, code always refers to the global shared variable gscSessionId, which you saw earlier in globals.i, rather than the session:server-connection-id. This is set during application start-up on the client. On the server it is set during session activation and reset on deactivation. The type of information that is stored by the framework itself in the context table includes user information, security information, etc.
The context table stores a date and time stamp for each value, indicating when it was last set and the name and value of the information itself. The context_name field is, therefore, just a property name.
Apart from a deleteContext call to destroy the context information for a user, the API that provides applications access to the context table is a function of property management.